Support FindTarantool to look for nonsystem tarantool #9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If a user have tarantool installed into custom directory he may specify path to tarantool installation using `TARANTOOL_DIR` variable like this: ```bash tarantoolctl rocks TARANTOOL_DIR=/path/to/tarantool/ install kafka ``` Luarocks will bypass this variable to cmake, which will use is to find its header files
olegrok
added a commit
that referenced
this pull request
Oct 30, 2021
Before this patch it was assumed that between event queues destroying and producer/consumer close there were no any event. However it's not so and tests catched it: ``` Process 46864 stopped * thread #4, name = 'coio', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x00007fff203fed86 libsystem_pthread.dylib`pthread_mutex_lock + 4 libsystem_pthread.dylib`pthread_mutex_lock: -> 0x7fff203fed86 <+4>: cmpq $0x4d55545a, (%rdi) ; imm = 0x4D55545A 0x7fff203fed8d <+11>: jne 0x7fff203fee02 ; <+128> 0x7fff203fed8f <+13>: movl 0xc(%rdi), %eax 0x7fff203fed92 <+16>: movl %eax, %ecx Target 0: (tarantool) stopped. (lldb) bt * thread #4, name = 'coio', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) * frame #0: 0x00007fff203fed86 libsystem_pthread.dylib`pthread_mutex_lock + 4 frame #1: 0x0000000102fdbba5 tntkafka.dylib`queue_push(queue=0x6d726554203a5d70, value=0x0000000102c1e0c0) at queue.c:92:5 [opt] frame #2: 0x0000000102fd7f9a tntkafka.dylib`log_callback(rd_kafka=<unavailable>, level=7, fac="DESTROY", buf=<unavailable>) at callbacks.c:56:17 [opt] frame #3: 0x000000011e5456f3 librdkafka.1.dylib`rd_kafka_log0 + 563 frame #4: 0x000000011e5469a0 librdkafka.1.dylib`rd_kafka_destroy_app + 832 frame #5: 0x0000000102fdb3be tntkafka.dylib`wait_producer_destroy(args=<unavailable>) at producer.c:414:5 [opt] frame #6: 0x000000010015d81e tarantool`coio_on_call + 23 frame #7: 0x00000001003019a7 tarantool`etp_proc + 395 frame #8: 0x00007fff204038fc libsystem_pthread.dylib`_pthread_start + 224 frame #9: 0x00007fff203ff443 libsystem_pthread.dylib`thread_start + 15 ``` To fix this issue let's reoreder code a bit and start to close producer/consumer before event queues destruction. This patch seems to help to solve an issue. Also I'd want to highlight that not all destructors should be placed after wait_producer_destroy/wait_consumer_destroy it seems topics they owns should be destroyed before. Otherwise it leads to an assertion. Also small code changes were performed to adjust code to Tarantool code-style and to make consumer_destroy and producer_destroy more consistent in sence of return values. Closes #44
filonenko-mikhail
pushed a commit
that referenced
this pull request
Nov 9, 2021
Before this patch it was assumed that between event queues destroying and producer/consumer close there were no any event. However it's not so and tests catched it: ``` Process 46864 stopped * thread #4, name = 'coio', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x00007fff203fed86 libsystem_pthread.dylib`pthread_mutex_lock + 4 libsystem_pthread.dylib`pthread_mutex_lock: -> 0x7fff203fed86 <+4>: cmpq $0x4d55545a, (%rdi) ; imm = 0x4D55545A 0x7fff203fed8d <+11>: jne 0x7fff203fee02 ; <+128> 0x7fff203fed8f <+13>: movl 0xc(%rdi), %eax 0x7fff203fed92 <+16>: movl %eax, %ecx Target 0: (tarantool) stopped. (lldb) bt * thread #4, name = 'coio', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) * frame #0: 0x00007fff203fed86 libsystem_pthread.dylib`pthread_mutex_lock + 4 frame #1: 0x0000000102fdbba5 tntkafka.dylib`queue_push(queue=0x6d726554203a5d70, value=0x0000000102c1e0c0) at queue.c:92:5 [opt] frame #2: 0x0000000102fd7f9a tntkafka.dylib`log_callback(rd_kafka=<unavailable>, level=7, fac="DESTROY", buf=<unavailable>) at callbacks.c:56:17 [opt] frame #3: 0x000000011e5456f3 librdkafka.1.dylib`rd_kafka_log0 + 563 frame #4: 0x000000011e5469a0 librdkafka.1.dylib`rd_kafka_destroy_app + 832 frame #5: 0x0000000102fdb3be tntkafka.dylib`wait_producer_destroy(args=<unavailable>) at producer.c:414:5 [opt] frame #6: 0x000000010015d81e tarantool`coio_on_call + 23 frame #7: 0x00000001003019a7 tarantool`etp_proc + 395 frame #8: 0x00007fff204038fc libsystem_pthread.dylib`_pthread_start + 224 frame #9: 0x00007fff203ff443 libsystem_pthread.dylib`thread_start + 15 ``` To fix this issue let's reoreder code a bit and start to close producer/consumer before event queues destruction. This patch seems to help to solve an issue. Also I'd want to highlight that not all destructors should be placed after wait_producer_destroy/wait_consumer_destroy it seems topics they owns should be destroyed before. Otherwise it leads to an assertion. Also small code changes were performed to adjust code to Tarantool code-style and to make consumer_destroy and producer_destroy more consistent in sence of return values. Closes #44
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If a user have tarantool installed into custom directory he may specify
path to tarantool installation using
TARANTOOL_DIRvariable like this:Luarocks will bypass this variable to cmake, which will use is to find
its header files